-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix(nextjs): Inconsistent transaction naming for i18n routing #17927
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(nextjs): Inconsistent transaction naming for i18n routing #17927
Conversation
size-limit report 📦
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sweet! Could we add a e2e test for this e.g. in next-15-basebath?
7e23ca1 to
68b20a8
Compare
|
I might've overdid it but testing the setup with other tests in place is tricky, so I set up another nextjs project with the actual intl-next package. |
68343f8 to
21c72bc
Compare
21c72bc to
89b04f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for adding the test! Since they all run in parallel and this is a fast one I'd not expect this to be a problem.
Great work!
Problem
When using Next.js 15 App Router with
next-intlandlocalePrefix: "as-needed", Web Vitals and transaction names were inconsistent across locales:/foo(default locale, no prefix) → Transaction:/:locale❌/ar/foo(non-default locale, with prefix) → Transaction:/:locale/foo✅This caused all default locale pages to collapse into a single
/:localetransaction, making Web Vitals data unusable for apps with i18n routing.After investigation it seems like the route parameterization logic couldn't match
/foo(1 segment) to the/:locale/foopattern (expects 2 segments) because the locale prefix is omitted in default locale URLs.Solution
Implemented enhanced route matching with automatic i18n prefix detection:
hasOptionalPrefixflag to route info to identify routes with common i18n parameter names (locale,lang,language)hasOptionalPrefix/foo→ tries matching as/PLACEHOLDER/foo→ matches/:locale/foo✓/:locale/foo(2 segments) now beats/:locale(1 segment)Result
After fix:
All routes now consistently use the same parameterized transaction name regardless of locale, making Web Vitals properly grouped and usable.
Backwards Compatibility
locale/lang/languageFixes #17775
Maybe we should make certain aspects of this configurable, like the
['locale', 'lang', 'language']collection